1. Field of the Invention
Exemplary embodiments of the present invention relate to software architectural models, and more particularly, to service-oriented architecture models.
2. Description of Background
A software architectural model is generally a set of components, connectors, constraints, containers, and configurations that provides reference architectural patterns and styles for a system. In recent years, the decoupling of interface from implementation at the programming level has become a popular architectural approach because such decoupling facilitates the creation of complex systems required by today's business applications. According to this approach, the interface of a service consumed by a service consumer is loosely coupled with its implementation by a service provider. This style has become the key characteristic of Service-Oriented Architecture (SOA); that is, rather than the implementations of components being exposed and known, only the service interfaces provided are published and consumers are insulated from the details of the underlying implementation by a provider or broker.
By providing a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains, SOA allows business and IT convergence through agreement on a set of business-aligned IT services that collectively support an organization's business processes and goals. Not only does it provide flexible, decoupled functionality that can be reused, but it also provides the mechanisms to externalize variations of quality of service; for example, in declarative specifications such as WS-Policy and related standards. Nevertheless, although SOA solutions have become a prominent topic in the modern business world, the design and development for SOA solutions is still carried out on an ad hoc basis, rather than in a systematic manner. Because of this, the establishment of an effective business-aligned service model to guide and facilitate the design, development, and management of highly reusable services and service components has remained a challenge.
In the preceding fifty years of software engineering development, an abundance of architectural models have been developed for use in guiding the design and development of traditional software applications. Nevertheless, due to the unique features of SOA requirements, the direct application of these architectural models to the SOA solution design and development process has encountered significant challenges. From the perspective of designing an integrated service model that addresses the linkage between business and IT, existing software application focused architectural models do not sufficiently encompass SOA-related needs such as, for example, the need for the system provided in an SOA solution to be centered around reusable services instead of specific software components, the need for an SOA solution to be adaptable to ever changing business requirements, etc.
Presently, the most well-known and widely accepted SOA architectural model that provides an underlying backbone for the creation, registration, and discovery of interface-exposed services is the triangular conceptual model. As illustrated in FIG. 1, an SOA triangular model 100 identifies three roles according to their behaviors and responsibilities over a service: a service provider 110, which offers services, a service requester 120, which invokes services, and a service registry 130, which helps service requestors to find service providers for proper services. More specifically, a service provider operates to publish services at a service registry, a service requestor queries the service registry for services in which it is interested and then connects to the corresponding service providers to invoke the services, and a service registry operates to register and organize published services and to provide search services.
Following the SOA triangular model, a new application may be developed initially for publication as a Web service into a service registry; alternatively, an existing software application, regardless of whether it is a packaged application, a customer application, or a legacy system, may be wrapped with a service-compliant interface and then published as a Web service. The encapsulated application in a Web service may comprise components at any granularity (which refers to the size and/or descriptions of the components that make up a system—systems of, or description in terms of, large components are called coarse-grained, and systems of small components are called fine-grained), ranging from a single application component to a comprehensive large-scale software product encompassing many components and other software products. Based upon this service model, a number of service wrapping and development platforms such as IBM's WebSphere and BEA's WebLogic, as well as a myriad of open-source software products, have been implemented and widely used in the market.
Nevertheless, a major drawback of the current triangular conceptual model is that it is too high level to adequately facilitate enterprise-level SOA solution design and development. Its application does not provide normative guidance on how to build a prototype of an SOA-enabled service. The triangular model also does not identify and address service handling-related issues such as decomposition, aggregation, transformation, and invocation in a systematic manner. Furthermore, because the triangular concept only models a very high-level system view that remains coarse-grained, SOA solution architects employing the model are forced to design component models for each service from scratch based upon personal knowledge and experience. This ad hoc approach can waste valuable human resources, result in schedule delays, and suffer from low reusability. Moreover, because the SOA triangular model handles reusable services at a coarse granularity, it does not support flexible and extensible business scenarios. The current triangular model does not provide architecture-level support for configuration and re-configuration of services and service components, and an SOA solution that is based upon the triangular model does not provide the adaptability needed to make run-time evolutionary changes.
Accordingly, it is desirable to create a fine-grained service model with the flexibility and extensibility to enable and support solution-level business service design and implementation in a systematic and unified manner.